Markup languages such as Hyper Text Markup Language (HTML) are commonly utilized today in order to describe and control how data is output to users of computing devices. For example, markup languages are used to describe web pages to be displayed by a browser, or screens to be displayed on a wireless, handheld computing device. As is known by those skilled in the art, markup languages generally comprise a series of tags, each of which can be associated with data. A tag can classify the data associated therewith, and tags can be associated with actions or behaviors. A markup language file is read by a rendering engine, which parses the markup language, identifies tags and associated data, and presents the corresponding output to a user according to the content of the markup language. For example, in HTML the tag <p> indicates the beginning of a paragraph, and the tag </p> indicates the end of a paragraph. When the tag <p> is encountered by a rendering engine, the rendering engine treats the subsequent data as a paragraph, until it encounters the tag </p>. Thus, the data between the <p> and </p> tags are presented to the user as a paragraph.
Markup languages are a useful way to describe the presentation of data, but they do have shortcomings. Often, it is necessary to perform the same action many times with different data. For example, suppose a truck driver who delivers grocery orders carries a hand held computing device containing information concerning each delivery on the driver's route. In order to execute a delivery, the driver consults a series of screens on the hand held device, each screen being generated by rendering markup language. To make a delivery, the driver would first view a screen with the name, address and phone number of the customer. Next, the driver would view a screen detailing the order, so that the driver could select the proper items from his truck. The next screen would allow the driver to process any items the customer wished to return. Another screen would allow the driver to record any items missing from the customer's order. Finally, another screen would process the payment.
As will be readily apparent, the same general screens would need to be replicated for each customer on the driver's route, but with different data each time. In order to do this with existing markup language technology, the same tag sets need to be repeated for each customer. This is not only very labor intensive and inefficient, but it is prone to error as well. For example, if a change is desired to an existing screen, the markup language pertaining to each instance of that screen must be edited. Often, one or more instances of a screen could inadvertently be omitted from this manual update procedure, such that the change would be applied for some but not all of the customers. Obviously, this is not acceptable.
Another shortcoming with existing markup languages is that data are associated with specific instances of tags such that the data cannot be reused without explicitly drafting additional markup language. If data are dissociated from their tags, the semantics are lost. For example, information concerning customers, orders and delivery items becomes meaningless once severed from the tags governing the display of that data in a specific and singular manner. As markup language is used today, information embedded within specific markup (e.g., customer, order, delivery time) is not reused because there is no automated, general-purpose way to determine the content of the information itself, for example which <p> element comprises a customer name and which the description of a carton of milk.
Yet another shortcoming with markup language is the need for the rendering computing device to be in contact with a server computer in order to process new data. To illustrate, suppose the truck driver in the example above needs to input the items that a specific customer wishes to return, or that are missing from the order. The screens generated from the markup language on the hand held device can not display this data, as this data is absent from the markup language. Instead, new markup language describing the items the customer entered would have to be drafted. To achieve this, generally the hand held computing device would have to transmit the data to a server computer, where new markup language would be created describing a screen that includes the newly entered items. The new markup language would then have to be transmitted back to the hand held device, and rendered locally to present the new screen. This is problematic, because communication with a server can be slow and expensive, especially over a wireless device where available bandwidth is limited. Worse yet, if the truck driver is located in a radio blackout zone, communication with a server is not possible at all.
What is needed is a method whereby the rendering and presentation of markup language allows for variable content, such that the same block of markup language can be used to describe the presentation of multiple data sets. In other words, a method is needed whereby a single block of markup language can be rendered so as to present, for example, a screen describing a customer's grocery list, for any customer and any list, without recoding the markup language or repeating the block. Additionally, the method should be able to embed information in markup language in a manner whereby the semantics of the information are preserved, such that the information can be referenced and used in multiple places in a single application, as well as in multiple applications. Furthermore, the method needs to be able to process new data in real-time, without requiring updated markup language, for example from a server computer.